iT邦幫忙

2025 iThome 鐵人賽

DAY 1
0
DevOps

30 天帶你實戰 LLMOps:從 RAG 到觀測與部署系列 第 1

Day01 - 為什麼需要 LLMOps?與傳統 MLOps 差異

  • 分享至 

  • xImage
  •  

🔹 前言

過去幾年,大家談 MLOps(Machine Learning Operations)時,重點都放在「如何讓機器學習模型可以產品化與維運」。 但隨著 GPT-4、LLaMA、Mistral 等大語言模型(Large Language Models, LLMs)的出現,我們發現:傳統的 MLOps 思維,已經不足以應付 LLM 的特性與挑戰

於是,「LLMOps」這個詞開始流行,專門針對 LLM 的開發、部署與維運問題。


🔹 傳統 MLOps 的挑戰解法

在傳統 MLOps 中,典型流程是:

  1. 資料收集與清洗 → DataOps
  2. 特徵工程(Feature Engineering)
  3. 模型訓練(Training)
  4. 模型部署(Serving)
  5. 模型監控(Monitoring & Retraining)

挑戰點:

  • 資料持續變動(Data Drift)
  • 模型效果衰退(Concept Drift)
  • 訓練與推論資源需求高
  • 需要 CI/CD for ML: MLflow, Kubeflow, TFX

🔹 為什麼 LLMOps 不一樣?

大語言模型跟傳統 ML 模型有幾個本質差異:

面向 傳統 ML 模型 大語言模型 (LLM) 帶來的挑戰
資料需求 小到中型資料集,自行蒐集/標註 使用網路大規模語料 (TB 級) 開發者很難自行重新訓練
訓練方式 常常自行訓練或 fine-tune 多數情況使用現成 API (OpenAI, Anthropic, HF) 訓練變成「提示工程 / 輕量調整」
部署模式 部署在內部伺服器或雲端,自己維運 透過雲端 API 或本地大模型(推論資源昂貴) 成本管理與 API 延遲更重要
監控 監控 Accuracy、Latency 還要監控「幻覺率」「毒性」「合規」 評估更偏質化,難自動化
迭代方式 Retrain + Deploy Prompt / RAG / LoRA 更快,但版本管理複雜

🔍 参考資料:
“From **MLOps to LLMOps: The evolution of automation for AI-powered applications”*(CircleCI,2024),指出,LLMOps 雖然沿用 MLOps 的基礎,但必須額外處理 治理、觀測性、成本控管、語言資料處理與即時響應,這也是為什麼需要新一套思維。


🔹 LLMOps 的核心要素

  1. Prompt & Prompt Template 管理

    • 不只是模型 code,而是提示詞也需要版本化。
  2. RAG Pipeline 維運

    • 文件切片 → Embedding → 向量資料庫 → 檢索 → 回答。
    • 要考慮資料更新、自動重建索引、效能優化。
  3. 觀測性 (Observability)

    • 除了 latency/cost,還要監控 幻覺 (hallucination)敏感資料洩漏不當輸出
  4. 成本與資源控管

    • Token 成本 ≠ 免費,API 呼叫次數要控管。
    • Caching、Hybrid 模型(小模型先答,大模型 fallback)是常見策略。
  5. 安全性與合規

    • Prompt Injection、防洩漏、防止濫用(特別是企業內部落地)。

🔹 舉例:客服問答系統的差異

📌 傳統 MLOps 的做法

假設公司要做一個「客服 FAQ 自動回覆系統」:

  1. 收集歷史客服對話,整理成 問題–答案 資料集。
  2. 用 TF-IDF / XGBoost / BERT 訓練一個分類器,判斷問題屬於哪個類別。
  3. 部署模型到 API Server。
  4. 每隔幾個月 retrain,避免因新產品上線而答案過時。

👉 特徵:資料量中等、可自己訓練、模型更新靠 retrain。


📌 LLMOps 的做法

如果我們用 LLM(例如 GPT-4o-mini)來解這個問題:

  1. 不用訓練模型,直接丟 prompt:「你是客服助手,回答以下 FAQ 問題」。

  2. 為了避免「亂回答」,要加上 RAG Pipeline

    • 客戶問題 → embedding → 向量資料庫檢索 → 找到最相關文件 → 塞進 prompt。
  3. 要做的維運工作是:

    • Prompt 管理(避免工程師改 prompt 後效果變差)。
    • 資料更新(新 FAQ 要即時進向量庫)。
    • 成本監控(每次 call API 都會花錢)。
    • 輸出檢測(避免回答「我們有 UFO 保固服務」這種幻覺)。

👉 特徵:不用自己訓練,但要處理 Prompt、資料、成本、輸出品質


📝 小結

MLOps 解決的是「如何讓一個訓練好的模型持續運作」,痛點是「如何持續 retrain 模型」。
LLMOps 解決的是「如何讓一個巨大的、通常不是你訓練的模型,能在現實業務中 安全、便宜、穩定 地跑起來」,而痛點是「如何讓模型行為可控、可監控、可持續」。

換句話說:MLOps 解決模型壽命週期,LLMOps 解決模型「行為」的生命週期

明天(Day02)我們要開始介紹這個系列的實作主線:「如何用 Free Tier + OpenAI API 打造一個企業知識庫 QA Chatbot」,並規劃我們的環境與工具組合。


📚 引用來源


下一篇
Day02 - 系列專案介紹:企業知識庫 QA Chatbot
系列文
30 天帶你實戰 LLMOps:從 RAG 到觀測與部署4
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言